Presto是一款Facebook开源的MPP架构的OLAP查询引擎，可针对不同数据源执行大容量数据集的一款分布式SQL执行引擎。因为工作中接触到Presto，研究它对理解SQL Parser、常见算子的实现（如SQL中table scan,join,aggregation）、资源管理与调度、查询优化（如向量化执行、动态代码生成）、大数据下各个组件为何适用不同场景等等都有帮助。我希望通过这个系列可以了解一条SQL在大数据场景下该如何高效执行。233酱准备不定时持续更新这个系列，本文主要从Presto的使用举例，Presto的应用场景、Presto的基本概念三个部分来初步介绍Presto。

presto 优点：

presto 缺点：

No fault tolerance；当一个Query分发到多个Worker去执行时，当有一个Worker因为各种原因查询失败，那么Master会感知到，整个Query也就查询失败了，而Presto并没有重试机制，所以需要用户方实现重试机制。

Memory Limitations for aggregations, huge joins；比如多表join需要很大的内存，由于Presto是纯内存计算，所以当内存不够时，Presto并不会将结果dump到磁盘上，所以查询也就失败了，但最新版本的Presto已支持写磁盘操作，这个待后续测试和调研。

MPP(Massively Parallel Processing )架构；这个并不能说其是一个缺点，因为MPP架构就是解决大量数据分析而产生的，但是其缺点也很明显，假如我们访问的是Hive数据源，如果其中一台Worke由于load问题，数据处理很慢，那么整个查询都会受到影响，因为上游需要等待上游结果。

　　presto不太支持存储过程，支持部分标准sql

　　presto的查询速度比hive快5-10倍

　　上面讲述了presto是什么，查询速度，现在来看看presto适合干什么

　　适合：PB级海量数据复杂分析，交互式SQL查询，⽀持跨数据源查询

　　不适合：多个大表的join操作，因为presto是基于内存的，多张大表在内存里可能放不下

　　和hive的对比：

　　　　hive是一个数据仓库，是一个交互式比较弱一点的查询引擎，交互式没有presto那么强，而且只能访问hdfs的数据

            presto是常驻任务，接受请求立即执行，全内存并行计算；hive需要用yarn做资源调度，接受查询需要先申请资源，启动进程，并且中间结果会经过磁盘。

　　　　presto是一个交互式查询引擎，可以在很短的时间内返回查询结果，秒级，分钟级，能访问很多数据源

　　　　hive在查询100Gb级别的数据时，消耗时间已经是分钟级了

　　　　但是presto是取代不了hive的，因为p全部的数据都是在内存中，限制了在内存中的数据集大小，比如多个大表的join，这些大表是不能完全放进内存的，实际应用中，对于在presto的查询是有一定规定条件的，比比如说一个查询在presto查询超过30分钟，那就kill掉吧，说明不适合在presto上使用，主要原因是，查询过大的话，会占用整个集群的资源，这会导致你后续的查询是没有资源进行查询的，这跟presto的设计理念是冲突的，就像是你进行一个查询，但是要等个5分钟才有资源继续查询，这是很不合理的，交互式就变得弱了很多

Presto架构：

Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。

Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。

Worker节点负责实际执行查询任务。

Discovery Server:Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。

如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。

一个查询分解为多个stage， 每个stage拆分多个task，每个task处理一个or多个split ，一个task被分解为一个或多个Driver。

Presto 使用 Catalog、Schema和Table 这3层结构来管理数据

catalog：就是数据源。每个数据源连接都有一个名字，一个Catalog可以包含多个Schema，大家可以通过show catalogs 命令看到Presto已连接的所有数据源。

schema：相当于一个数据库实例，一个Schema包含多张数据表。通过以下方式可列出catalog_name下的所有 Schema：show schemas from 'catalog_name'

Table：数据表，与RDBMS上的数据库表意义相同。通过以下方式可查看'catalog_name.schema_name'下的所有表：show tables from 'catalog_name.schema_name'

在Presto中定位一张表，一般是catalog为根，例如：一张表的全称为 hive.test_data.test，标识hive(catalog)下的 test_data(schema)库中 test 表。可以简理解为：数据源的类别.数据库.数据表。

语句（Statement）：Presto执行ANSI兼容的SQL语句。当Presto提起语句时，指的就是ANSI标准的SQL语句，包含着列名、表达式和谓词。之所以要把语句和查询分开说，是因为Presto里，语句知识简单的文本SQL语句。而当语句执行时，Presto则会创建查询和分布式查询计划并在Worker上运行。

查询（Query）：当Presto解析一个语句时，它将其转换为一个查询，并创建一个分布式查询计划（多个互信连接的stage，运行在Worker上）。如果想获取Presto的查询情况，则获取每个组件（正在执行这语句的结点）的快照。查询和语句的区别是，语句是存SQL文本，而查询是配置和实例化的组件。一个查询包含：stage、task、split、connector、其他组件和数据源。

Stage：当Presto执行查询时，会将执行拆分为有层次结构的stage。例如，从hive中的10亿行数据中聚合数据，此时会创建一个用于聚合的根stage，用于聚合其他stage的数据。层次结构的stage类似一棵树。每个查询都由一个根stage，用于聚合其他stage的数据。stage是Coordinator的分布式查询计划（distributed query plan）的模型，stage不是在worker上运行。

Task：由于stage不是在worker上运行。stage又会被分为多个task，在不同的work上执行。Task是Presto结构里是“work horse”。一个分布式查询计划会被拆分为多个stage，并再转为task，然后task就运行或处理split。Task有输入和输出，一个stage可以分为多个并行执行的task，一个task可以分为多个并行执行的driver。

Split：Task运行在split上。split是一个大数据集合中的一块。分布式查询计划最底层的stage是通过split从connector上获取数据，分布式查询计划中间层或顶层则是从它们下层的stage获取数据。

Presto调度查询，coordinator跟踪每个机器运行什么任务，那些split正在被处理。

Driver：Task包含一个或多个并行的driver。Driver在数据上处理，并生成输出，然后由Task聚合，最后传送给stage的其他task。一个driver是Operator的序列。driver是Presto最最低层的并行机制。一个driver有一个输出和一个输入。

Operator：Operator消费，传送和生产数据。如一个Operator从connector中扫表获取数据，然后生产数据给其他Operator消费。一个过滤Operator消费数据，并应用谓词，最后生产出子集数据。

Exchange：Exchange在Presto结点的不同stage之间传送数据。Task生产和消费数据是通过Exchange客户端。

比如说，你想对存储在不同数据源中的数据，如HDFS、Mysql、HBase等通过一个SQL做查询分析，那么只需要把每一个数据源当成是Presto的Connector，对应实现Presto SPI暴露出的Connector API就可以了。

hbase 和 es 的Join查询举例

Presto官方版和Presto社区版已经支持了很多Connector，社区版略胜一筹。至于两者有何区别，吃瓜群众可以前往文末参考资料[4]。简而言之，都主要由Facebook那帮大佬核心维护。社区版更新更为频繁，但高版本需要JDK11才能支持；官方版JDK8就行，官方版的Star数是社区版的10倍左右，选哪个就一目了然了吧。

Presto是为了处理TB/PB级别的数据查询和分析，它是OLAP(Online Analytical Processing)领域的一个计算引擎。参考资料[1]提到了Presto在Facebook中的使用场景有：

做过报表和大盘的小伙伴应该对这个场景下复杂的SQL有所了解。这个场景下的使用用户是Facebook内部或外部人员，通常要求：高QPS，低时延(_